The following applications of common assignee contain some common disclosure, and are believed to have an effective filing date identical with that of the present application:
U.S. patent application entitled xe2x80x9cPerformance Optimization In a Heterogeneous, Distributed Database Environmentxe2x80x9d.
U.S. patent application entitled xe2x80x9cPass Through In a Distributed Multi-Database Systemxe2x80x9d.
U.S. patent application entitled xe2x80x9cPush Down Optimization in a Distributed, Multi-Database Systemxe2x80x9d.
The above-listed applications are incorporated herein by reference in their entireties.
1. Technical Field
The present invention relates generally to computer database systems, and more particularly to functional compensation in a heterogeneous, distributed database environment.
2. Background Art
In modern data processing environments, a client""s data is often distributed among a plurality of heterogeneous database systems (more precisely, a client""s data is distributed among a plurality of database instances which were instantiated from different database management systems). xe2x80x9cHeterogeneous database systemsxe2x80x9d are database systems that have different data definition and manipulation procedures, security procedures, system management approaches, capabilities, etc. Examples of xe2x80x9cheterogeneous database systemsxe2x80x9d include DB2 produced by International Business Machines (IBM) Corporation, Oracle produced by Oracle Corp., Sybase produced by Sybase Inc., etc. Such heterogeneous database systems, when used together, collectively represent a heterogeneous, distributed database environment (or system). Heterogeneous, distributed database systems are also sometimes called federated database systems and/or multi-database systems.
In order to enhance user-friendliness, it is preferred that clients be provided with a common interface to all of the heterogeneous database systems (heterogeneous database systems to which a client is not directly connected are called back-end database systems, or simply back-ends). In other words, it is preferred that clients be under the illusion that they are interacting with a single database system.
One conventional approach for achieving this goal is to introduce an interface module between the clients and the back-end database systems. This interface module, also called database middleware or data access middleware, attempts to provide to clients transparent access to the back-end database systems. Generally speaking, the interface module receives data definition and manipulation instructions from clients. The interface module translates these instructions such that they are understandable to the appropriate back-end database systems, and then transfers the translated instructions to the appropriate back-end database systems. Similarly, the interface module translates information and messages received from the back-end database systems such that they are understandable to the appropriate clients, and then transfers the translated information and messages to the appropriate clients.
Generally, back-end database systems support different sets of functions. For example, some back-end database systems (such as DB2) support the declaration of cursors xe2x80x9cwith holdxe2x80x9d. Other back-end database systems (such as current versions of Oracle and Sybase) do not support this function.
Some conventional interface modules address this functional dissimilarity problem by relying on a xe2x80x9cleast-common denominatorxe2x80x9d approach wherein the only functions that are supported are those functions that are supported by all of the back-ends. This is not an optimal approach, however, because it does not allow clients to take advantage of all of the functions offered by all of the back-ends.
Other conventional interface modules address the functional dissimilarity problem by disallowing the use of functions when operating with back-ends that do not support the functions. Such functions are allowed when operating with back-ends that do support the functions. This is not an optimal approach, however, since it violates location transparency. That is, clients must be aware of which back-ends they are interacting with.
Thus, what is needed is an improved system and method for addressing the functional dissimilarity problem in a heterogeneous, distributed database environment.
The present invention is directed to a system and method of compensating for functional differences between heterogeneous database management systems, wherein data associated with a client is distributed among the heterogeneous database management systems. The present invention simulates support of multiple pending actions on a single connection in any of the heterogeneous database management systems which does not support multiple pending actions on a single connection. Also, the present invention: (1) simulates support of cursors declared xe2x80x9cwith holdxe2x80x9d in any of the heterogeneous database management systems which does not support cursors declared xe2x80x9cwith holdxe2x80x9d; (2) simulates support of positioned update actions in any of the heterogeneous database management systems which does not support positioned update actions; (3) simulates support of host variables in any of the heterogeneous database management systems which does not support host variables; and (4) compensates for security log-in procedure differences between the heterogeneous database management systems.
Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.